今天筆者要來介紹最近很紅的 Spec-Driven Development（SDD，規格驅動開發）。 這套方法不是叫 AI 自由發揮，而是先把需求、規則、架構與驗收方式講清楚，再讓 AI 按圖施工。 聽起來是不是很像找一位不太會讀心術、但很會照文件做事的工程師？沒錯，重點就是不要讓 AI 自己腦補到外太空去 🚀

🧭 SDD 其實不是全新的東西
SDD 之所以突然爆紅，主要是因為 AI 產生的程式碼不一定是最好的。 它可以幫我們快速產生功能，但如果沒有規範，最後很容易變成「看起來有寫，實際上不能維護」的程式碼山。

沒想到筆者滑臉書時，居然發現這個概念早在 2004 年就有人提出來了。 當時的精神就是用 specification 來驅動開發，把需求與驗收條件定義好，接著按照規格實作。 這也提醒筆者一件事：很多 AI 時代的新名詞，骨子裡可能只是老觀念穿了新衣服啊。

🧓 新瓶裝舊酒，但不代表沒價值
SDD 的核心概念並不新，但 AI coding agent 讓這套方法變得更容易落地。 以前要自己維護文件、拆解工作與檢查一致性，現在可以交給工具輔助處理。

🥋 先守規則，再破規則，最後離開規則
在開始談 SDD 前，筆者想先分享一個在 Agile 裡學到、自己覺得很實用的觀念： 守、破、離。

守：Follow the Rule
先學會既有的流程、原則與最佳實務，把基本功練好。

破：Break the Rule
理解規則後，開始挑戰它，找出更適合團隊與情境的做法。

離：Be the Rule
不再被框架綁住，能自己設計方法，也能把經驗分享給別人。

因此，筆者不會把 SDD 當成「每個專案都必須百分之百照做」的宗教。 我會先學它怎麼定義文件、怎麼拆解流程、怎麼讓 AI 逐步執行， 接著再思考哪些部分適合自己的團隊。流程是拿來幫忙的，不是拿來供奉的，這點很重要。

🧩 SDD 的三個核心概念
筆者把 SDD 拆成三個主要概念：Intent、Artifacts、Review。 簡單講，就是先說清楚要做什麼，再留下開發過程的文件，最後由人來檢查 AI 產出的結果。

01 Intent
先定義清楚目標: 先說明使用者需要什麼、為什麼需要，以及完成後什麼樣子才算成功。 目標越模糊，AI 腦補越精彩，通常也越容易精彩到讓筆者想重開機。

02 Artifacts:
把決策留下來: 透過 constitution.md、spec.md、 plan.md 與 tasks.md 等文件， 把需求、技術設計與工作項目放在程式碼旁邊。

03 Review
人不能完全下班: AI 可以產生程式碼，但需求是否正確、架構是否合理、驗收是否真的通過， 還是要由人來判斷。Copilot 很強，但它不會替你背鍋，這點要先講在前面。

📜 constitution.md：先訂專案的憲法
在 Spec Kit 裡，先建立一份專案層級的規則，通常會放在 constitution.md。這份文件就像專案憲法，所有功能開發都要遵守。

限制條件一定要寫: 實務上最容易漏掉的，往往不是「要做什麼」，而是「不能做什麼」。 哪些技術不能用、哪些 API 不准直接呼叫、哪些資料不能落地、哪些權限一定要驗證， 這些限制如果不寫，AI 通常會選它覺得方便的路，然後我們就要負責填坑。

📝 spec.md：需求一定要能驗收
接下來是功能需求，也就是 spec.md。 筆者在這裡特別強調一件事：驗收規則一定要寫進去。

例如不要只寫「使用者可以上傳檔案」，這句話太空泛了。 應該補上允許哪些檔案格式、檔案大小上限、上傳成功後會看到什麼結果， 以及權限不足或上傳失敗時要怎麼處理。 能被觀察、能被測試、能被確認，這才叫驗收條件。

🏗️ plan.md：把需求翻成技術設計
當需求確認後，就進入 technical design，也就是產生 plan.md。這一步是在回答：「這個功能要怎麼放進現有系統？」

筆者通常會在這裡確認前端與後端元件、資料儲存方式、API 設計、權限控制、 錯誤處理與復原策略。以常見的企業應用程式為例，可能會使用 React UI、 .NET API、Azure Blob Storage 儲存檔案，再用 SQL 儲存中繼資料。

其實現在很多 coding agent 已經有類似的流程：先問需求、再提出方案， 然後詢問要不要開始實作。SDD 只是把這個過程制度化，並且把每一步的結果留下來。 原本以為只是聊天，結果居然變成有文件、有流程、還有紀錄的開發作業，這就是它有價值的地方。

🛠️ tasks.md：把設計拆成可以執行的工作
有了 plan 之後，接下來就是產生 tasks.md。 它會把技術設計拆成一個個有順序、可執行、可檢查的工作項目。

筆者會在這個階段再執行一次 analyze，確認需求、設計與工作項目之間沒有互相打架。 如果發現 spec 說要用 A，plan 卻規劃成 B，這時候修正還來得及； 等到程式都寫完才發現，通常就是「頭都洗下去了，只好繼續洗」的狀態。

🚀 Spec Kit 的工作流程，簡單看一次
上面的流程可以濃縮成一句話： 先定義規則，再定義需求；先規劃技術，再拆解工作；最後才讓 AI 實作。

更多實作Demo，請參考完整版影片囉

💸 本日結論：SDD 很完整，但也真的很燒 Token
這裡筆者要誠實講，SDD 好用歸好用，但它不是沒有代價。 因為每個階段都會產生文件，也會讓 AI 反覆讀取規則、需求、設計與工作項目， 所以 Token 使用量一定會增加。

SDD 的現實成本
文件變多，需要花時間維護。
流程變長，小功能可能顯得太重。
AI 每次讀取更多上下文，Token 消耗會增加。
如果需求本來就很清楚，完整流程未必比直接下 Prompt 快。
所以筆者不會把 SDD 吹成萬靈丹。 小型一次性腳本，直接請 AI 寫，可能比較有效率； 但如果是多人協作、長期維護、需求容易變動，或是需要強調安全性與可測試性的專案， 那麼把規格留下來，通常可以為自己省下很多後續溝通與除錯的咖啡時間 ☕

SDD 的重點不是「多寫幾份 Markdown」而已，而是讓需求、設計、任務與程式碼彼此對得起來， 讓 AI 不只是幫忙打字，而是依照規則參與整個開發流程。

當然，流程不是越完整越好，適合自己的才是好流程。 所以筆者才會先提守、破、離，然後再依照專案需求調整，千萬不要看到別人有十個步驟， 自己就硬要每次十個步驟全部走完，結果功能還沒開始，文件先寫到天荒地老，然後燃燒吧 Token 。